pathogens: Define workflows in top level key of nextstrain-pathogen.yaml#472
Merged
pathogens: Define workflows in top level key of nextstrain-pathogen.yaml#472
nextstrain-pathogen.yaml#472Conversation
joverlee521
force-pushed
the
workflow-compatibility
branch
from
d117abe to
e701c24
Compare
joverlee521
added a commit
to nextstrain/pathogen-repo-guide
that referenced
this pull request
Sep 23, 2025
Workflow changes to support running the workflows with the `nextstrain run` command. I specifically chose _not_ to declare compatibility for `nextstrain run` in the `nextstrain-pathogen.yaml` because the phylogenetic and nextclade workflows are incomplete in this guide. Once workflow specific compatibility is supported,¹ we can declare compatibility for the ingest workflow. ¹ <nextstrain/cli#472>
2 tasks
2 tasks
tsibley
suggested changes
Sep 23, 2025
Contributor
tsibley
left a comment
tsibley
left a comment
There was a problem hiding this comment.
I continue to +1 for the change in nextstrain-pathogen.yaml! My comments here are almost all around the way workflows are exposed in Nextstrain CLI. Happy to discuss my suggestions if you want to consider them. But also, if you are happy not to care about the details, I can make the changes as I see fit instead of going back and forth here.
joverlee521
added a commit
that referenced
this pull request
Sep 23, 2025
Dropping based on feedback #472 (comment)
joverlee521
added a commit
that referenced
this pull request
Sep 23, 2025
Declutter the version output for pathogen worklfows but still keeping a simple list of pathogen workflow names for discoverability. Based on feedback <#472 (comment)>
joverlee521
added a commit
to nextstrain/zika
that referenced
this pull request
Sep 23, 2025
Depends on merge and release of nextstrain/cli#472
2 tasks
joverlee521
added a commit
to nextstrain/measles
that referenced
this pull request
Sep 23, 2025
Depends on merge and release of nextstrain/cli#472
2 tasks
joverlee521
added a commit
to nextstrain/mumps
that referenced
this pull request
Sep 23, 2025
Depends on merge and release of nextstrain/cli#472
2 tasks
tsibley
added a commit
that referenced
this pull request
Sep 24, 2025
…run` compatibility
Workflows are now registered under a top level "workflows" key in the
nextstrain-pathogen.yaml file, and each workflow has its own
"compatibility" declarations. The only current "compatibility"
declaration remains "nextstrain run".
This allows for more meta information about each workflow to be
registered in one place not under the banner of compatibility.
The nextstrain-pathogen.yaml schema changes to a workflow-first
structure like:
workflows:
ingest:
compatibility:
nextstrain run: yes
phylogenetic:
compatibility:
nextstrain run: no
instead of a compatibility-first structure like:
compatibility:
nextstrain run:
ingest: yes
phylogenetic: no
as previously introduced¹ (but not yet released). As it was never
released, don't bother supporting the latter schema at all anymore.
Change first arose out of discussion started by @victorlin in a related
PR.² Subsequent discussion with @tsibley³ led to dropping support for
the unreleased schema.
¹ <#461>
² <#462 (comment)>
³ <#472 (comment)>
Co-authored-by: Thomas Sibley <[email protected]>
tsibley
added a commit
that referenced
this pull request
Sep 24, 2025
List the workflow names on the same line as the pathogen name@version when there are any workflows and emit nothing when there aren't. This fits more in the style of the rest of `nextstrain version` and is much less cluttered (more information dense), particularly considering that we, in short order too, expect ~all of our pathogens (and all their future versions) to have the same 2–3 workflows listed (nextclade, ingest, phylogenetic). Prompted by feedback from @tsibley.¹ ¹ <#472 (comment)> Co-authored-by: Thomas Sibley <[email protected]>
tsibley
force-pushed
the
workflow-compatibility
branch
2 times, most recently
from
fad921c to
8e98a95
Compare
tsibley
added a commit
that referenced
this pull request
Sep 24, 2025
…run` compatibility
Workflows are now registered under a top level "workflows" key in the
nextstrain-pathogen.yaml file, and each workflow has its own
"compatibility" declarations. The only current "compatibility"
declaration remains "nextstrain run".
This allows for more meta information about each workflow to be
registered in one place not under the banner of compatibility.
The nextstrain-pathogen.yaml schema changes to a workflow-first
structure like:
workflows:
ingest:
compatibility:
nextstrain run: yes
phylogenetic:
compatibility:
nextstrain run: no
instead of a compatibility-first structure like:
compatibility:
nextstrain run:
ingest: yes
phylogenetic: no
as previously introduced¹ (but not yet released). As it was never
released, don't bother supporting the latter schema at all anymore.
Change first arose out of discussion started by @victorlin in a related
PR.² Subsequent discussion with @tsibley³ led to dropping support for
the unreleased schema.
¹ <#461>
² <#462 (comment)>
³ <#472 (comment)>
Co-authored-by: Thomas Sibley <[email protected]>
tsibley
added a commit
that referenced
this pull request
Sep 24, 2025
List the workflow names on the same line as the pathogen name@version when there are any workflows and emit nothing when there aren't. This fits more in the style of the rest of `nextstrain version` and is much less cluttered (more information dense), particularly considering that we, in short order too, expect ~all of our pathogens (and all their future versions) to have the same 2–3 workflows listed (nextclade, ingest, phylogenetic). Prompted by feedback from @tsibley.¹ ¹ <#472 (comment)> Co-authored-by: Thomas Sibley <[email protected]>
Contributor
|
Repushed with tweaks to the code and commit messages. |
Contributor
|
I'll merge once I get tests to pass… |
…run` compatibility
Workflows are now registered under a top level "workflows" key in the
nextstrain-pathogen.yaml file, and each workflow has its own
"compatibility" declarations. The only current "compatibility"
declaration remains "nextstrain run".
This allows for more meta information about each workflow to be
registered in one place not under the banner of compatibility.
The nextstrain-pathogen.yaml schema changes to a workflow-first
structure like:
workflows:
ingest:
compatibility:
nextstrain run: yes
phylogenetic:
compatibility:
nextstrain run: no
instead of a compatibility-first structure like:
compatibility:
nextstrain run:
ingest: yes
phylogenetic: no
as previously introduced¹ (but not yet released). As it was never
released, don't bother supporting the latter schema at all anymore.
Change first arose out of discussion started by @victorlin in a related
PR.² Subsequent discussion with @tsibley³ led to dropping support for
the unreleased schema.
¹ <#461>
² <#462 (comment)>
³ <#472 (comment)>
Co-authored-by: Thomas Sibley <[email protected]>
List the workflow names on the same line as the pathogen name@version when there are any workflows and emit nothing when there aren't. This fits more in the style of the rest of `nextstrain version` and is much less cluttered (more information dense), particularly considering that we, in short order too, expect ~all of our pathogens (and all their future versions) to have the same 2–3 workflows listed (nextclade, ingest, phylogenetic). Prompted by feedback from @tsibley.¹ ¹ <#472 (comment)> Co-authored-by: Thomas Sibley <[email protected]>
Helpful to ensure that their directories exist as expected to catch registration vs. reality mismatches.
tsibley
force-pushed
the
workflow-compatibility
branch
from
8e98a95 to
20c99d4
Compare
joverlee521
added a commit
to nextstrain/measles
that referenced
this pull request
Sep 26, 2025
Depends on merge and release of nextstrain/cli#472
joverlee521
added a commit
to nextstrain/zika
that referenced
this pull request
Sep 26, 2025
Depends on merge and release of nextstrain/cli#472
joverlee521
added a commit
to nextstrain/pathogen-repo-guide
that referenced
this pull request
Oct 31, 2025
Workflow changes to support running the workflows with the `nextstrain run` command. I specifically chose _not_ to declare compatibility for `nextstrain run` in the `nextstrain-pathogen.yaml` because the phylogenetic and nextclade workflows are incomplete in this guide. Once workflow specific compatibility is supported,¹ we can declare compatibility for the ingest workflow. ¹ <nextstrain/cli#472>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of proposed changes
Originally implemented as part of #462. Pulled out as a separate PR since other changes in the original PR are being discussed.
NOTE: This is changing the schema for the workflow registration originally added (but not yet released) in #461.
List workflows under a top level
workflowskey in thenextstrain-pathogen.yamlfile where each workflow has it's owncompatibilitykey:The top levelDropped support for top level compatibility declaration as discussed.compatibility['nextstrain run']boolean is still supported for backwards compatibility.Checklist
Post-merge/release